1. Field of the Invention
The present invention relates to automated process control and in particular to improved methods and systems for batch process control wherein a phase logic module operable in accordance with a state machine model is integrated within a programmable controller or within a data processing element.
2. Discussion of Related Art
Batch Processing
There are many types of industrial processes. Some run continuously until stopped, typically producing very large quantities of product between start-up and shutdown. Other industrial processes operate on groups of parts, with the group moving as a unit between workstations but with each part maintaining its own unique identity.
A third type of industrial process is the batch process, which involves subjecting raw materials to processing steps using one or more pieces of equipment to produce a "batch" of product. Cooking is an example of a batch process practiced in the home. Raw food is prepared, is placed in a pan, is cooked for a time specified by a recipe, and ends up as a dish or "batch" ready for eating.
Preparation of polyvinyl chloride is an example practiced on an industrial scale. Polyvinyl chloride is made by polymerizing or "joining together" much smaller molecules of vinyl chloride. This is accomplished by filling a batch reactor to the appropriate level with a mixture of vinyl chloride, solvent and polymerization inducer, heating the mixture in the reactor, cooling the resulting batch, and purifying the batch by removing leftover starting materials.
These are but a few examples of batch processes. In general, there are many different kinds of batch processes. They may include, for example, product manufacturing, distribution, and testing as well as several other product and non-product oriented processes.
Batch Process Control
Generally speaking, it is important to control a batch process. For one example, if a dish is left on the stove for too long during cooking, it will burn and the resultant batch of food will be ruined. For another example, if a reaction mixture of vinyl chloride is not reacted long enough, the yield of polyvinyl chloride from the process will be inadequate and money will be lost. Control of a batch process can become critical where production of dangerous chemicals or comparable entities is involved.
One way to control a batch process is manually. That is, one or more workers are assigned the job of watching all aspects of batch process to be sure that everything is proceeding according to plan. However, this is tedious work, and errors can creep in unnoticed.
For these and other reasons, workers in the field of batch control have been trying for some time now to automate the control of batch processes by using electronic devices. Computers, programmable controllers and comparable electronic devices have been used in conjunction with intelligent field devices (i.e., intelligent sensors and controllable valves) by a number of batch control system suppliers to automate the control of batch processes.
An intelligent sensor is typically placed on a piece of equipment and reports on equipment conditions to a central control room in the plant. A controllable valve typically controls the input to, or output from, a piece of equipment, and can be controlled from a central control room, often based on information received from an intelligent sensor.
Efforts to automate batch processing have led to the formation of standards committees by members of industries involved in batch processing and suppliers of batch processing equipment, among others. The general purpose of these standards committees has been to define uniform standards for automated batch processing.
One such standard has been promulgated by the International Society for Measurement and Control, an international organization concerned with issues of process control. This standard is entitled Batch Control Part 1: Models and Terminology and is often referred to as the ISA S88.01-1995 standard (or "S88" for purposes of this application).
The S88.01 standard defines models of equipment and procedures for use in automated batch processes, as well as terminology for use in referring to those models and their elements. The S88.01 standard defines a "batch process" as a process that leads to the production of finite quantities of material by subjecting quantities of input materials to an ordered set of processing activities over a finite period of time using one or more pieces of equipment. A "batch" is defined as the material that is being produced or has been produced by a single execution of a batch process.
Procedural Model
Batch-processing equipment (i.e., controllable elements such as valves, heaters, mixers, etc.) is operated according to procedures to make a batch. For purposes of this application, all such equipment is referred synonymously to as equipment, equipment modules, processing equipment, or physical element. The procedures to operate such physical elements are often referred to by the S88.01 standard as the "procedural model." According to the S88.01 standard, the procedural model is structured as a hierarchical ranking of procedures, with the highest level encompassing each of the lower levels, the next highest level encompassing each of the levels below it, and so on. The levels of the S88.01 procedural model of particular interest for purposes of this application are, in descending order:
the "procedure" PA1 the "unit procedure" PA1 the "operation" PA1 the "phase"
The term "procedural element" is used in this application to refer to any embodiment or implementation of any of these levels of the S88.01 procedural model, not just to those of the "procedure" level or any other single level of the procedural model.
The highest-level procedural element of interest is referred to as a procedure, which is made up of one or more unit procedures. Each unit procedure is in turn made up of one or more operations, which are each in turn made up of one or more phases. The S88.01 procedural model does not preclude definition and use of other hierarchical levels, nor does it require that each level be present in particular applications. Rather, the standard is intended to provide a broad, standardized model for describing the procedures followed in automated batch-process control.
FIG. 8 graphically depicts the hierarchical relationship of procedural elements defined by the S88.01 standards. A procedure 800 is comprised of one or more unit procedures 802. Each unit procedure 802 is comprised of one or more operations 804. Each operation 804 is generally comprised of one or more phases 806. As noted above each phase is generally in communication with one or more units 820 (a collection of process equipment physical elements) collectively referred to as a process cell 825 to effectuate the desired control of a batch process. As also noted above, other higher level elements of the procedural model are generally abstractions of the lower level elements (i.e., operations are abstractions of one or more phases, etc.).
Linkage of Physical and Procedural Elements
In general, procedural elements are implemented as computer programs that are executed by and within data-processing devices, including personal computers, workstations, and programmable controllers. Execution of a typical procedural element results in an electrical or optical output from the data-processing device that can be used to control a physical element, typically by connecting an output of the data-processing device to the physical element directly, or indirectly over a local-area or wide-area network.
A procedural element performs its assigned task by invoking "basic control" with respect to at least one physical element. This type of control is dedicated to establishing and maintaining a specific desired state of the physical element. Basic control would, for example, start or maintain a flow of material in a storage bin element or heating of starting materials in a polyvinyl chloride reactor element.
In practice, the lower levels of the procedural model (namely phases) perform the actual communications with the actual physical elements thereby invoking or performing basic control. The higher levels of the procedural model are essentially abstractions to improve organization and structure of the procedural model, and the physical model as well.
Procedural Elements and the State Machine Model
A state machine model is a logical construct commonly used to describe the state of a process or activity. The model describes or defines a number of process states, together with actions that cause transitions between those states. A state machine model of a process is said to be in a particular state due to an earlier transition into that state. When a particular event occurs or a particular status is sensed, the state machine model makes a transition to another state corresponding to the particular event or sensed status.
A state machine model is a useful technique for defining and implementing the operation of a procedural element of a batch process. A procedural element defined and implemented as a state machine initiates an action, for example, when its associated state machine makes a transition from an old state to a new state.
The S88.01 standard permits definition and implementation of procedural elements in accordance with a standard state machine model. While the S88.01 standard does not mandate this approach, it has been broadly adopted in the process control industry to enable a higher degree of interoperability among the products of various vendors (as explained further below). One present commercial application of the S88.01 standard having procedural elements defined and implemented according to a state machine model is the OpenBatch.TM. product from PID, Inc. at 2429 West Desert Cove Avenue, Phoenix, Ariz. 85029.
In OpenBatch, a server program runs on the data processing device that executes procedural elements. The server program coordinates execution of procedural elements in accordance with one or more state machine models. Procedures, corresponding unit procedures, corresponding operations, and corresponding phases are sequenced through their respective steps by the server program.
When a phase is initiated by the server program, for example, the phase communicates the initiation request to the phase logic interface within a programmable controller. The programmable controller then executes the actual state logic for the phase and provides the required process control through communications to the process equipment.
FIG. 7 depicts a typical phase communicating with one or more typical physical elements as presently known in the art. Phase 704 is operable within a batch server program 702 on a data processing device 700. State machine model 706 is operable within phase 704 to control the operation of the phase in accordance with a standard state model. Phase 704 communicates with one or more programmable controllers 710 via communication path 750. Programmed instructions in the programmable controller 710 provide one or more phase logic interfaces 712, one for each phase which uses the programmable controller 710.
Each phase logic interface 712 provides a mapped register communication interface for exchange of information with a phase 704. The mapped register communication interface, discussed further below, includes a number of registers 718 and a map 720 of the allocation of the registers. The information exchanged through the mapped registers 718 is used by phase logic 714 to implement the desired control functions in association with the state machine 706 operating within the phase 704. In other words, phase logic 714 is designed and implemented by the control engineer to mirror the operation of the state machine in the data processing device. State logic sequences 716 integrated with phase logic 714 executes the actual control sequences required to control the batch process.
Problems in the Art
A problem arises when each manufacturer implements a different means and method for communicating the requisite information between the data processing device and the programmable controller. Because of this, communications between a phase in the data processing device and the phase logic interface in the programmable controller may be very different from the communications required for another brand of programmable controller, even though both programmable controllers perform essentially the same function.
The result is that a process control design engineer may need to design, implement, and maintain a large volume of custom software to permit a particular phase to communicate with, for example, an Allen-Bradley programmable controller, and simultaneously design, implement, and maintain an entirely separate volume of custom software to permit the phase to communicate with, for example, a Fisher-Rosemount systems, Inc. PROVOX programmable controller. This overlap of effort is inefficient and wasteful.
Further, a common communication interface known in the art for a number of equipment manufacturers is a register model. The phase logic interface presents itself to the procedural element as a large set of registers--readable and/or writable storage locations for exchanging information between the phase within the data processing device and the phase logic interface in the programmable controller. The registers are logically mapped by the control engineer into necessary aspects of control for a phase. Logic corresponding to functions defined by the control engineer for each register of a phase is implemented in the programmable controller phase logic interface by the control engineer. The map of registers as used by a particular phase is maintained by the control engineer. Though there exist tools to aid in documenting the mapping of registers for a phase, the task remains largely a manual task and the responsibility of the control engineer.
As a batch process changes and evolves, the documentation for the register mapping must be maintained and updated--another largely manual process for the control engineer. Further, where there are multiple phases in a batch process, each phase uses a number of such logically mapped registers to implement basic control for that phase. It is common for large, complex batch processes to define hundreds if not thousands of phases involved in the production of a batch. The task of generating and maintaining a usable map documenting each phase and the corresponding registers used in performing requisite controls is indeed a daunting one.
For example, it is typical for a phase in a programmable controller to utilize approximately 15 registers to implement required control sequences for a single phase. A typical batch process may include approximately 100 phases to perform the processing of a batch. The control engineer is therefore responsible for initially defining and maintaining a map describing approximately 1500 registers. Where more programmable controllers are used for a larger batch process and where more phases are required for more complex batch processes, the number of registers to be mapped may grow quite large.
Furthermore, aspects of the state machine model of a phase must be communicated between the data-processing device executing the phase and the programmable equipment controller of the corresponding equipment module. In essence, portions of the server program's state machine model need to be understood and stored within the programmable controller. This further complicates the programming and engineering tasks because these functions are often not well understood by process control engineers. In addition, the control languages implemented within most programmable controllers are generally not well suited for the implementation of state machine logic and are generally not transportable between programmable controllers developed by different manufacturers. Though some of the program instructions for tracking the state machine model could be copied for implementing the control logic for each phase, the replicated code sequences would still require testing. Each of the instructions sequences would require detailed testing to assure proper operation of the batch process in each state for each phase implemented in he programmable logic controller.
Still further problems arise in present techniques in that when a failure occurs in processing of a phase, there are no standard techniques for communicating appropriate failure processing information between the data processing device performing the phase and the programmable controller performing the requisite basic control. Rather, again, the control engineer has been responsible for designing and maintaining a unique failure processing method and associated program instructions and communication paths for exchanging control information regarding the failure.
Yet another problem arises in prior techniques where processing of a phase requires performing processing within a non-standard device. For example, a phase may require certain forms of user (operator) input to perform its phase processing. The requisite input may be obtained from a user input device such as a keyboard, display or barcode reader. Such devices do not generally utilize the register model communication standards commonly used in exchanging information between a phase in a data processing device and programmable controller phase logic interface. Current techniques therefore require yet another form of communication and processing with the phase to implement such phase processing.
It is apparent from the above discussion that a need exists for an improved method and structure for communicating phase control information and related state and failure information between procedural elements (i.e., phases) in the data processing device and the phase logic in the programmable controller.